Day 7 講的是畫面跟架構怎麼收斂，比較偏單一功能範圍內的判斷。今天想再往下深講一層，遇到真正需要做出架構決策的情況時，像是要不要換一個框架、系統要怎麼分層、一個新方向值不值得做，這種影響範圍大、沒有簡單標準答案的判斷，我實際上是怎麼產出一份架構規劃的。
這種決策以前在團隊裡通常會拉一群資深工程師開會，各自從自己熟悉的角度講意見，吵一吵才有共識，會議室裡總是有人負責提醒大家某個框架已經換了新版本、有人負責質疑一個看起來理所當然的假設、有人負責把最後的結論寫成大家都看得懂的會議紀錄。現在只剩我自己一個人，這個過程不會因為人少就消失，是要換一種方式重建出來。
架構決策常常需要在幾個框架或做法之間選，這種選擇最怕的是根據過時的資訊做判斷，一個函式庫半年前的版本跟現在的版本，用法可能已經差很多，棄用的 API 可能已經棄用了，新的最佳做法可能才剛出來。模型本身知道的東西有個時間點，超過那個時間點之後發生的事，它不會主動知道，除非有辦法讓它去查現在真正的文件。
我自己現在做架構相關的判斷之前，會先透過一個專門抓即時文件的工具，把要用到的框架或函式庫的最新文件抓進來，讓判斷是根據現在真正的寫法在做，不是根據訓練時期記得的舊版本語法。這件事聽起來小，但差別很大，用舊語法寫出來的架構草案，有些做法可能早就被官方標成不建議使用，甚至已經整個換了一套新的慣例，這種落差如果沒抓出來，等到真的動手才發現，要付的代價會比一開始多花幾分鐘查證高出許多。
實際用起來的感覺是，我在討論要不要採用某個框架的某個做法時，會先讓它去查這個框架現在的官方文件寫了什麼，而不是讓它憑印象回答。憑印象回答的東西讀起來通常很順、很有自信，這正是最危險的地方，跟前面講過的道理一樣，聽起來篤定不代表是對的，只有真的去查證過的東西才算數。這個習慣我現在幾乎變成反射動作，只要牽涉到某個外部工具或框架的具體用法，一律先查再判斷，不會讓它憑記憶回答，就算是我自己覺得應該很熟的東西，也會照樣查一次，畢竟連我自己的印象都可能是過時的。
先確保資訊是新的這件事，對架構規劃特別重要的原因是，架構決策常常一次要比較好幾個框架或工具，如果對每一個的了解都停留在訓練時期的印象，比較出來的結果本身就建立在不可靠的基礎上，等於是拿幾個過時的版本在比較，比較的過程做得再嚴謹，結論也不會可靠，這種情況下，先確保資訊是新的，比任何比較方法本身都更根本，順序一旦顛倒過來，後面做得再仔細都是白工，追不回來。
架構決策我自己現在不會一個人從頭想到尾，會組一組角色，各自負責不同的分析工作，同時進行。有的角色負責盤點現有系統長什麼樣子，現在的程式碼實際上是怎麼組織的，有哪些既有的限制，這個角色我會要求它老實回報現況，不要順便給建議，混雜建議進去，後面的分析角色看到的就不是乾淨的現況，會被提早污染。有的角色負責針對某個候選方向，去分析這個方向的優缺點、適不適合現在的規模、未來擴充會不會卡住，這個角色我會明確劃定它只負責自己那個方向，不去比較其他方向好不好，比較的工作留到後面統一做，不要每個角色各自帶著偏見去貶低別的方向來凸顯自己負責的那個。同一件事，如果有好幾個候選方向要比較，我會讓每個方向各自有一個角色去分析，全部同時進行，不用一個做完才換下一個，這樣每個方向都是站在同樣中立的起點被認真看過，不會有先發優勢或後發劣勢的問題。
這樣做的好處很直接，以前架構決策要嘛靠自己一個人熬夜想，要嘛真的要找幾個資深工程師開會討論，現在變成我可以同時派出好幾個角色去做這些分析，各自回來的東西再由我自己整合判斷。速度快很多，而且因為是分開分析，不會有人受到另一個人先講的意見影響，每個方向都是獨立被認真看過一次，不是順著第一個提案的方向去補強。
這件事我會特別要求同時派出去，不是排隊一個做完換下一個。這幾個分析工作彼此不需要對方的結果才能開始做，屬於前幾天講過的彼此獨立的事，排隊做只是把等待時間疊加起來，同時派出去，實際花的時間取決於最慢的那一個，不是全部加總，這個習慣光是套用在架構規劃這種一次要比較好幾個方向的場景，省下來的時間就很有感。
派工的時候，我也會明確交代每個角色要回報的格式，比較哪個方向、優點是什麼、缺點是什麼、有沒有明顯不適合現在這個專案的地方，全部要求附具體理由，不能只給一個籠統的印象分數。這個要求跟前面幾天講的回報要有固定格式是同一件事，架構分析這種資訊量大的工作，格式不固定，我自己事後要花更多時間去理解每個角色到底想表達什麼，反而抵銷了分頭進行省下來的時間。
除了格式，我也會要求每個角色講清楚自己的判斷是根據什麼，是查了現在的官方文件、還是根據現有程式碼的實際狀況、還是單純的經驗判斷，這三種來源的可信度不一樣，混在一起講很容易讓人誤以為一個經驗猜測跟一個查證過的事實一樣可靠。分清楚來源之後，技術負責人在做最後綜合判斷的時候，才知道哪些內容可以直接採信，哪些內容需要多留一個心眼，這個標記來源的習慣，我覺得是整套流程裡最容易被忽略、卻最值得堅持下去的一個小細節，忽略它的代價不會馬上顯現，通常是等到某個猜測被當成事實一路往下推論很久之後，才會突然發現整條推論根本站不住腳。
這個團隊裡的角色，我不會全部用同一個等級的模型去跑。負責盤點現況、整理既有程式碼結構這種偏事實蒐集的工作，用中等等級的模型做就好，這類工作要的是仔細跟完整，不是深度判斷。真正要做取捨、要综合各種分析結果、最後拍板要走哪個方向的角色，我會明確指定用最強的模型去扮演，這個角色我自己會定位成技術負責人的角色，所有分析結果最後都匯到這裡，由這個角色綜合判斷，給出真正的建議。
這件事我自己覺得比想像中重要，因為架構決策的成本很不對稱，分析階段用便宜一點的資源省下來的時間跟金錢很有限，但最後拍板決策如果判斷錯了，代價往往是整個系統要花好幾週才能修正過來的方向錯誤。便宜資源該省的地方省，真正貴的判斷不該省，這條界線在架構決策這種高風險的場景特別重要，省錯地方省下來的那一點點成本，跟後面要付出的代價比起來，完全不成比例。
技術負責人這個角色我會挑目前能力最強的模型去扮演，因為這個角色要做的事，是把好幾份各自獨立、甚至彼此矛盾的分析結果，綜合成一個有道理的建議，這種需要同時裝進好幾種考量、還要拿捏輕重的工作，正是最考驗判斷力的地方，不是隨便一個等級的模型都扛得住。這個角色我自己會明講給它，它扮演的是整個團隊裡最終要為判斷負責的位置，這句交代看起來像廢話，但我自己感覺得出來，講清楚這個角色的份量之後，給出來的分析深度會比只交代「幫我整理一下結論」扎實一些，這跟前幾天講的道理一樣，交代動機這件事，會影響對方怎麼選擇處理事情的方式，只是這裡沒有正式做過對照，只是我自己主觀的感覺，不敢講得太篤定。這個角色收到的不是原始資料，是前面幾個角色已經整理過的分析，它的工作是站在這些分析之上做綜合判斷，不是重新去做前面已經做過的事，分工分清楚，每個角色才不會做重複的工作，也不會有兩個角色各自默默重做同一件事，浪費掉原本平行處理該省下來的時間，這件事看似枝微末節，實際排起來卻很容易被忽略。
整個分析跟決策做完之後，產出的東西不能只是一段對話紀錄，不然事後要回頭看，得從一堆來回訊息裡自己撈重點。我現在會把架構規劃整理成一份可以直接呈現、可以分享出去的產物，裡面包含比較了哪些方向、各自的優缺點、最後選了哪個、為什麼選這個，用結構化的方式排版，讓人一眼就能看懂整個判斷的脈絡，不用自己從對話裡東拼西湊。
Claude 自己有一個功能可以做到這件事，把產出直接變成一個獨立呈現的頁面，可以是一份排版過的文件，也可以是圖表，甚至是一個能互動的簡單網頁，不是只能貼一段純文字。架構規劃這種需要比較好幾個方向、需要表格或圖示輔助理解的內容，用這種方式呈現，比純文字報告好讀很多，而且這個產出是獨立存在的東西，不會隨著對話往下捲動就被埋掉，需要的時候可以直接叫出來看，不用往回翻一堆訊息去找。
這個功能我自己覺得最實用的地方，是它可以邊做邊修改，看到某個地方排版不順、資訊擺得不對，直接講要怎麼調整，不用整份重新產生一次。架構規劃這種常常要來回調整用詞、調整比較方式的內容，這種可以局部修改的特性幫助很大，不然每次調整都要整份重寫，反而增加不必要的來回成本，也容易在重寫的過程中不小心遺漏掉前面已經確認過的細節。
這種可以直接呈現的產物，做出來之後不只是自己看，也可以直接拿給別人看，不管是要跟其他人討論，還是之後自己要回頭確認當初為什麼這樣決定，都比一段純文字的對話紀錄好用很多。這也呼應了前幾天一直在講的道理，判斷要寫成文件，這裡的文件不一定是純文字，也可以是排版過、結構清楚的產出，只要能讓人不用重新問一次就看懂當初的判斷過程，都算數，格式從來就不是重點，能不能被看懂才是。
我自己會要求這份產出至少包含幾個固定的區塊，比較的方向有哪些、每個方向的優缺點、最後的建議、還有一個明確標出哪些地方不確定、需要我自己再確認的區塊。最後這一塊我特別看重，架構分析常常會有幾個地方是分析角色自己也拿不準的，這種地方不能被寫得好像很篤定，一定要明確標出來，這樣我自己在看這份產出的時候，才知道哪裡可以直接採信，哪裡還需要自己再想一次。
這個固定格式我自己套用久了之後，發現它有個附加的好處，不同時間做的幾次架構規劃，因為都用同一套格式呈現，回頭比較起來也很方便，不用每次都重新適應一套新的敘述方式，也更容易發現某個判準是不是前後不一致。這件事跟前面幾天講的設計系統要定一次規則、不要每次重新想，是同一個道理，只是這裡固定下來的不是視覺規則，是架構規劃這份產出本身的格式。
即使技術負責人這個角色用了最強的模型，給出來的建議我還是會自己再核對一次，不會因為它是團隊裡等級最高的角色，講的話就自動變成對的。核對的方式是回頭看它引用了哪些前面角色的分析，這些引用有沒有斷章取義，有沒有選擇性地只挑對某個結論有利的部分講，默默忽略掉對這個結論不利的證據。這件事跟前幾天講的道理一樣，換人驗證這件事，不能因為換的人等級比較高，就跳過驗證這一步，等級高只代表判斷力比較強，不代表不會犯錯。
我自己也遇過技術負責人這個角色給的建議，理由講得很完整，但回頭去對照原始分析，發現它其實漏看了其中一個角色特別提到的一個重大限制，整份建議是在不知道這個限制的情況下做出來的。這種狀況如果沒有回頭核對，我會直接照著一個有漏洞的建議往下走，這也是為什麼再厲害的角色給的結論，我都會留一道自己核對的手續，不會因為它排在整個流程的最後一關，就默認它一定是對的。
核對這件事花的時間不多，通常就是快速掃過建議裡引用的幾個關鍵點，回頭對照原始分析有沒有斷章取義，這道手續比重新自己做一次架構分析省事很多，但省下來的不是核對這件事本身，是省下事後照著一個有漏洞的建議走了一段路才發現問題、還要往回修正的成本，這筆帳跟前幾天講過的道理一樣，早一點花小成本核對，遠比晚一點花大成本修正划算。
架構規劃跑出來的東西，最後會餵進先前講過的那套先想清楚再動手的流程裡，變成規劃階段真正要拿來討論、要逼問、要確認清楚的素材。沒有這一步，規劃模式或者逼問的功能，面對的會是一個空空的想法，逼問不出什麼實質內容，因為根本沒有具體的候選方案可以逼問。架構規劃是把「有哪些選項、各自的取捨是什麼」這件事先攤開，後面的逼問跟收斂，才有真正具體的東西可以對焦。
順序反過來也不行，如果沒有先做這一輪分析就直接進到逼問，逼問的角色只能針對一個方案挑毛病，看不到其他本來就存在但沒被考慮過的方向，這樣做出來的決策，品質會比先比較過幾個方向再逼問差一截。
具體串起來的做法是，架構規劃那份產物做完之後，我會把裡面最後選定的方向，連同放棄的其他方向跟放棄的理由，一起交給規劃模式跟逼問的角色去看。逼問這時候問的問題會更精準，因為它手上有完整的比較脈絡，可以直接問「你們也考慮過另一個方向，為什麼最後沒選它，這個決定在現在這個情境下還站得住腳嗎」，這種問題如果沒有前面的架構分析當底稿，根本問不出來，因為連有哪些候選方向存在都不知道。
架構規劃裡標成待確認的項目，也會直接變成逼問清單裡最優先要處理的幾條，不用另外重新想要問什麼，前面分析階段就已經把最該問的問題準備好了。這種串接讓整個從架構決策到需求收斂的過程變得比較連貫，不會每進到下一階段就從零開始，前一階段留下的疑點會一路被帶著走，直到真正被解決為止，不會走著走著就不見了，變成沒人記得當初有這個疑問，也不會因為換了個階段、換了個角色，就把前面辛苦盤點出來的疑點又重新遺失一次。
老實講清楚這整套做法的界限。組團隊去分析、用最強模型做決策，能解決的是資訊蒐集不全、判斷過程沒有系統性比較這類問題，解決不了的是這個專案本身要往哪個方向走，這種涉及商業判斷、資源限制、未來規劃的事，架構分析可以把技術面的取捨講清楚，但要不要為了某個商業目標犧牲一部分技術上的乾淨度，這種決定還是要回到我自己身上，沒有任何角色能替我做這個判斷。
還有一個限制，也是我自己吃過虧才注意到的，這些分析角色不管派出多少個、再怎麼認真仔細，都是根據現有資訊做判斷，如果一開始給的背景資訊本身不完整，比如沒講清楚未來半年這個系統預期會成長到什麼規模，分析出來的建議很可能是根據錯誤的假設在推論，這種情況下，問題不在分析做得好不好，是一開始交代的背景就不夠，這也是為什麼我自己在派出這個團隊之前，會先確保背景資訊講得夠清楚，把已知的限制條件一次講完，不會讓分析角色自己憑空猜測專案的限制條件。
還有一種狀況我自己遇過不只一次，幾個分析角色各自看起來都很有道理，各自的邏輯也都講得通，單獨看都挑不出毛病，但仔細比對會發現彼此的假設不一致，一個假設系統會快速成長，一個假設規模會維持穩定，兩個假設不能同時成立。這種時候我不會直接採信講得比較篤定的那份，會回頭去確認到底哪個假設才是真的，這也是為什麼技術負責人這個角色的工作不只是選一個結論，還要有能力看出送進來的分析彼此之間有沒有互相矛盾的地方，這種比對工作沒有捷徑，只能靠那個角色認真讀過每一份分析才做得到。
這種矛盾一旦抓出來，我不會叫技術負責人自己猜哪個假設對，這種涉及專案實際狀況的事實問題，答案從來就不在任何一個分析角色手上，一直都在我自己手上，只有我知道這個系統接下來半年真正的規劃是什麼。抓到矛盾之後，正確的處理方式是把這件事明確標成待我確認，不是讓技術負責人用猜的方式硬選一個假設繼續往下推論，這種地方猜錯了，後面整份建議都建立在錯的前提上，白費工夫，這也是這系列一路強調的紅線，缺一個事實，寧可停下來問，不能用猜的補上去。
跟前幾天講過的道理一樣，不是每個架構決策都值得動用整套組團隊分析的流程，這件事本身也需要花力氣交代背景、寫清楚要比較什麼，不是免費的。一個小範圍、影響有限、錯了也很好改回來的技術選擇，我自己憑經驗判斷就好，不需要為了這麼小的事，花時間交代背景、派角色、等分析結果，那樣反而是把簡單的事情弄複雜。真正值得動用這套做法的，是那種一旦定案就很難回頭、會有大量後續程式碼建立在這個決定之上的架構層級選擇，這種決定的代價夠高，才划算花時間走完整套流程。
判準我自己抓得很直接，跟前面幾天講過的判準是同一套，這個決定要是選錯了，多久之後才會被發現，發現之後要花多久才能修正回來。如果答案是很快就會發現、修正成本也不高，直接憑經驗選一個就好。如果答案是要等系統長到一定規模才會發現、發現了要大改，那就值得花時間組團隊認真分析一次。
這個判準我自己這陣子套用下來，發現真正需要走完整套流程的決策，其實沒有想像中那麼多，大部分的日常技術選擇，憑經驗當下判斷就夠了，反而是那種一開始看起來普通、後來才發現牽連很廣的決定最容易被低估。抓不準的時候，我會傾向先當作值得認真分析來處理，這跟前幾天講的偏保守判準是同一個道理，多花一點時間分析，比事後發現漏了才回頭補划算，這個偏保守的習慣，代價是偶爾會多花一點不必要的分析時間，但比起漏掉一個真正重要的決定，這個代價我自己覺得划得來。
以前架構決策這種事，公司裡通常會有一群資深工程師坐下來一起討論，每個人從自己熟悉的角度發表意見，最後由技術負責人拍板。現在這整個委員會的功能，變成我自己一個人要想辦法重建，抓即時文件是確保討論的基礎資訊是新的，組團隊分頭分析是重建多人各自從不同角度看問題的效果，指定一個角色用最強模型扮演技術負責人，是重建那個最後要拍板、要為決定負責的角色，產出可呈現的規劃文件，是重建會議紀錄跟決策文件的功能。
這件事我自己一開始沒有想得這麼清楚，只是單純覺得多派幾個角色去查資料、去分析比較快，後來實際做久了，回頭看才發現這幾個角色湊起來，剛好對應到一個真正的架構會議裡會出現的每一種功能，沒有一個是多餘的，也沒有明顯缺少哪一塊。這個發現讓我對這套做法更有信心，不是因為它看起來很厲害，是因為拆開來看，每一塊都能對應到一個以前確實需要真人才能提供的功能。
唯一真正沒辦法被取代的，是那個要為決定負責、承擔後果的人，這個位置不管交給哪個角色扮演，最後真正扛起後果的還是我自己。技術負責人這個角色給的是建議，不是責任，責任這件事從頭到尾都沒辦法外包給任何一個角色，這條界線我自己看得很清楚，不會因為有一個角色講得很像真的技術負責人，就把最終該由自己承擔的判斷責任也一併交出去，這句話講起來像場面話，但我自己每次拍板前都會刻意提醒自己一次，不讓自己不小心把責任也連同工作一起交出去，這個提醒的動作，比想像中更容易被自己省略掉。
這幾件事全部湊起來，才勉強撐得住一個人做出原本需要一群人才做得出來的架構判斷，缺了任何一塊，這個決策的整體品質都會跟著打折，這也是一路強調的同一件事，一個人要跑完整條開發線，靠的不是自己變得無所不能，是把原本分散在不同人身上的各種功能，一項一項想辦法重建回來。
寫到這裡回頭看，從需求定義的逼問跟文件化，到畫面架構的盤點跟收斂，再到今天架構規劃的組團隊分析，這幾件事表面上做的事情很不一樣，逼問、盤點、分析，用詞都不同，但拆到最底層，都是同一個結構，先確保資訊是乾淨、對齊、夠新的，再讓一個有份量的判斷立場去做真正的取捨，最後留一手讓自己回頭核對，不管套進哪個階段，這個結構都成立，換的只是每個環節具體要用什麼工具去實現而已。
今天講的這一整套組團隊分析架構的做法，跟前面幾天比起來，是目前為止最接近多人協作的一次具體示範，前面幾天大多是我自己跟一兩個角色來回，今天是同時有好幾個角色各自產出，再匯到一個角色手上綜合，某種程度上已經很接近一個小型專案在跑的樣子，只是所有的人都是我自己在調度，開會的人、記錄會議的人、最後拍板的人、承擔決定後果的人，全部都是同一個我。
下面講下一個場景，會進到實作階段，看架構規劃定案之後，怎麼確保寫出來的東西真的照著這份規劃走，不會做到一半又悄悄跑偏，變成一個誰都沒真正同意過的方向。
iThome鐵人賽
看影片追技術